I am back + BGP next hop resolution using an LSP

Hello!!! It’s been a long time! Life has been crazy in the last 2 years , and I know that is an understatement, and that every single one of you would agree 100%

I for instance changed jobs, caught Covid and completely freaked out, had a monoclonal treatment (to avoid complications due to MS) and recovered, got vaccinated, fell down the stairs and hurt my tail bone, have become pretty sedentary, gained weight, had to stop doing TKD….

I know we all have our stories, and I should admit, mine has not been bad in comparison with so many, but I cannot pretend this has not affected my mood, discipline, and overall health, and has diminished my enthusiasm for studying, learning and writing. Gosh! I have become a better procrastinator!

Granted, my new job has been exceptionally challenging, which I was not expecting! For starters, I had to learn about Kubernetes to be able to understand, explain, and help people install, and troubleshoot our Paragon Automation products. Seriously, I was not even sure how to spell Kubernetes a few months ago, but I now know enough to follow what’s going on under the hood with Paragon Automation… I should write about that! So, I did study and learned some things! 🙂

A lot of challenges ahead: I need to learn more about all the features and tools available with Paragon Automation which are many and very cool!!! I have to recertify my JNCIEs, get my CCNP back, and maybe, just maybe, try the JNCIE-CLOUD. Need to start writing frequently again, get back in shape and return to TKD (back on track for 4th degree).

For now, let me talk a little about BGP next hop resolution using an LSP. One of my customers was asking me about this today, and I thought: “let me put together a little example for him”, and then I said: “let’s add it to momcanfixanything!” so here we go:

Here is our starting point:

Simple stuff: R6 is advertising 192.168.1.0/24 to R5 using EBGP, ISIS is advertising the loopback addresses of the routers inside AS 200.

Now, do you remember the main (default) rules for the BGP (protocol) next-hop?

For EBGP sessions:  

• The BGP next hop of a route generated by a BGP router, and advertised to an EBGP neighbor, is set to its local address (source address used for the BGP session). In our example, R5 and R6 are peering using the IP addresses of the interface that directly connects the two. Thus, when R6 generates and advertises the route to 192.168.1.0/24 to R5, it sets the BGP next hop to its address 172.16.1.2.

• The protocol next hop of a route received from another BGP router (either EBGP or IBGP) and advertised to an EBGP neighbor is changed to the local address (source address used for the BGP session) of the router advertising the route. In our example, if R6 was receiving the route to 192.168.1.0/2 from another router (R7 for example – see diagram below), it would still set the next hop to its address 172.16.1.2 when advertising the route to R5 (EBGP neighbor).

For IBGP sessions:

• The BGP next hop of a route generated by a BGP router, and advertised to an IBGP neighbor, is still set to its local address (source address used for the BGP session). If R5 was generating a BGP route for its loopback address 100.0.0.5/32, and advertising it to its IBGP neighbor R2 it would advertise it with its own local address. Since it is common practice to configure IBGP using loopback addresses, that would mean that R5 advertises its route for 100.0.0.5/32 to R2 with a next-hop of 5.5.5.5

• The BGP next hop of a route received from another BGP router (either EBGP or IBGP) and advertised to an IBGP neighbor is NOT changed to the local address (source address used for the BGP session) of the router advertising the route. In our example, R5 receives the route to 192.168.1.0/2 from R6, and advertises it to R2 without changing the next-hop from 172.16.1.2.

The key is to distinguish between routes generated by the router itself, in which case, it does not matter what kind of neighbor the route is being advertised to, vs. routes received from another neighbor, in which case the type of neighbor the route will be advertised to does matter.

Now, when a BGP router receives a route, the first two things it will do, before looking at all the attributes (local preference, AS-PATH length, etc.), are these:

1. Make sure the route has not crossed its own autonomous system (loop avoidance) – this needs its own article.
2. Make sure it knows how to get to the BGP next-hop.

The next hop validation makes perfect sense if you think about it this way:

R2 is telling R3 that in order to send traffic to Prefix A, it has to send it to R1. The logical question for R3 to ask would be: “and how do I get to R1?”

Back to our sample topology, we know that:

• R6 is advertising a route for 192.168.1.0/24 to R5 with a next hop of 172.16.1.2.
• R5 receives the route and advertises it to R2, but because R2 is an IBGP neighbor, the next hop is not changed.
• R2 receives the route and says: “OK, do I know how to get to the BGP next-hop of this route (172.16.1.2)?”

Because the link between R5 and R6 is not part of ISIS, the answer to the question will be NOPE!

The route to 192.168.1.0/24 will not be valid, it cannot be used for forwarding, and will only be visible if you add the hidden knob to the show route command. The route will show that the next-hop is unusable (cannot be resolved to a known physical directly connected next-hop).

The easiest way to solve it is to change the default next-hop behavior in R5, and make it change the next-hop to itself before advertising the route to R2.

Once again, R2 will ask himself: “do I know how to get to the BGP next-hop?”

This time because R5 is changing the next-hop to its own loopback interface address, and this interface is part of ISIS, R2 will be able to answer the question as: “yes! to get to the BGP next-hop 5.5.5.5, I need to send the traffic to R4 (10.1.2.2) out of interface ge-0/0/1.0”

As a result, R2 installs a route to 192.168.1.0/24 with next hop of 10.1.2.2 via ge-0/0/1.0 and all traffic destined for devices on 192.168.1.0/24 is sent via R4.

Now, here is where we can make this interesting:

We can create an LSP between R2 and R5, and force it to go through R3:

Notice that now R2 has a route to 5.5.5.5 (the loopback address of R5), also with a next hop of 10.1.2.2 via ge-0/0/1.0, but including the label-switch-path R2-to-R5 in inet.3. Check my article about routing tables for more details.

BGP has the ability to check both inet.0 and inet.3 to perform next-hop resolution. As a result, the BGP route to 192.168.1.0/24 will be resolved to the LSP is inet.3, and the route installed in inet.0 will point to the LSP.

Any traffic sent to 5.5.5.5 will still follow the ISIS route in inet.0, and will be forwarded via R4 (Forwarding is always based on the contents of inet.0) while traffic to 192.168.1.1 will be sent via R3 using the LSP.

One thing to always remember is that this magic is only possible when you make sure that the BGP next-hop of the route is the exact same as the egress address of your LSP!

BGP JNCIP-ENT JNCIP-SP Routing